The present invention is related to the management of an operating system of a computer entity, and more particularly to the management of data of settings of such an operating system.
An operating system comprises several independent software components. These software components are in charge of:                managing the computer entity hardware, and        managing the computer entity network services and/or providing high level user interface programs.        
Most of these software components have their own settings and own running behaviours. Usually, the software component settings are stored in a standard text file. Some of these software components may provide a graphical user interface to allow a user to configure the settings of the software components.
In order to manage the operating system (for example a thin client operating system), an end user should be provided with:                several Graphical User Interfaces (or “GUI”) for configuring the computer entity hardware and/or the Operating System (or “OS”) program services,        the ability to configure the OS by different means:                    using a GUI available on the OS,            using an existing network management protocol (for example SNMP),            using a proprietary network management tool,                        the ability to extract the OS configuration and to import it on another OS.        
Any provided program (including the so-called “GUI” programs) for configuring the OS directly can update each software component configuration file and then restart the corresponding software component with the settings based on the configuration chosen by the end user.
Then, all provided programs or GUI needing to update a software component have to know:                an address of the configuration file of this software component,        how this software component should be restarted,        and which other dependent software component needs to be updated also.        
A first difficulty is met in integrating heterogeneous components into an OS. Software components have to be updated or even sometimes be replaced by other software components. Consequently, any program in charge of configuring this software component has to be updated also because configuration files path are deprecated. Software component behaviour could also change. Moreover, usual integrators or administrators may not have access to configuration program sources.
A second difficulty is met in centrally managing heterogeneous component settings. Each software component has its own configuration file and several programs could exist to configure one same software component. So each of these programs can have its own way to edit and update one software component configuration file. Moreover, two configuration programs can have access to the same software component configuration file at the same time which can lead to data corruption.
A third difficulty is met in handling interactions between all software components. An operating system, in the end, comprises a multiplicity of software components and configuration programs. Because interactions and dependencies between software components can be managed in several places, some software components may be not synchronized with their configuration files. Settings required by an end user may not be applied to all software components.
The present invention aims to improve the situation.